QRZ! Ham Radio 3/QRZ Ham Radio Callsign Database - Volume 3.iso/digests/tcp/930299.txt

Internet Message Format | 1994-06-04 | 22KB

Date: Wed, 17 Nov 93 04:30:03 PST
From: Advanced Amateur Radio Networking Group <[e-mail]>
Errors-To: [e-mail]
Reply-To: [e-mail]
Precedence: Bulk
Subject: TCP-Group Digest V93 #299
To: tcp-group-digest


TCP-Group Digest            Wed, 17 Nov 93       Volume 93 : Issue  299

Today's Topics:
                    Maybe We Found The Problem...
                   RE wnos4a9 wno4a9ps.zip (2 msgs)
                  SLIP, AX.25, KISS, Etc... (6 msgs)
                 UCSD master nameserver for ampr.org
                             wnos-5 more

Send Replies or notes for publication to: <[e-mail]>.
Subscription requests to <[e-mail]>.
Problems you can't solve otherwise to [e-mail].

Archives of past issues of the TCP-Group Digest are available
(by FTP only) from UCSD.Edu in directory "mailarchives".

We trust that readers are intelligent enough to realize that all text
herein consists of personal comments and does not represent the official
policies or positions of any party.  Your mileage may vary.  So there.
----------------------------------------------------------------------

Date: Tue, 16 Nov 93 14:08:49 UTC
From: [e-mail]
Subject: Maybe We Found The Problem...
To: [e-mail]

I don't recall his name, but he sent a message about all of the KEPS junk, and
I got these TWO replies:

-----------------------------------------------------------------------------
>From [e-mail] Tue Nov 16 13:02:27 1993
Received: from vnet.ibm.com by N8WEI.AMPR.ORG (JNOS1.10x13) with SMTP
 id AA993 ; Tue, 16 Nov 93 13:02:04 UTC
Received: from TORVM3 by vnet.IBM.COM (IBM VM SMTP V2R2) with BSMTP id 4343;
   Tue, 16 Nov 93 12:39:19 EST
Date: 16 Nov 1993 12:39:12
From: TORVM3
To:   [e-mail]
Subject: Message from KLASSEN at TORVM3
Status: R

 On course. Will check for msgs daily.

 The mail you sent has been archived.

 This message was sent by the SAFE automatic machine: do not reply.

>From [e-mail] Tue Nov 16 13:55:05 1993
Received: from vnet.ibm.com by N8WEI.AMPR.ORG (JNOS1.10x13) with SMTP
 id AA1002 ; Tue, 16 Nov 93 13:54:56 UTC
Received: from TORVM3 by vnet.IBM.COM (IBM VM SMTP V2R2) with BSMTP id 5115;
   Tue, 16 Nov 93 13:08:14 EST
Date: 16 Nov 1993 13:08:06
From: TORVM3
To:   [e-mail]
Subject: Message from KLASSEN at TORVM3

 On course. Will check for msgs daily.

 The mail you sent has been archived.

 This message was sent by the SAFE automatic machine: do not reply.


-----------------------------------------------------------------------------

Hmmmmm....


73's  DE  N8WEI...

C-Ya'...

    *---------------------------------*------------------------------------*
    |  ((N8WEI) TCP/IP) PBBS 147.560  |       Todd W. Powers (N8WEI)       |
    | ------------------------------- |      4245 Stonebridge Road SW      |
    | Packet Radio:                   |         Wyoming, MI  49509         |
    |   N8WEI @ N8WEI.AMPR.ORG        | ---------------------------------- |
    |   N8WEI @ N8WEI.#SWMI.MI.USA.NA |                                    |
    | Internet:                       |  Borland C++ & FoxPro Programmer   |
    |   N8WEI @ HAMGATE.GVSU.EDU      |                                    |
    *---------------------------------*------------------------------------*

------------------------------

Date: Wed, 17 Nov 93 09:26:00 CET
From: BARRY TITMARSH <[e-mail]>
Subject: RE wnos4a9 wno4a9ps.zip
To: TCP-GROUP <[e-mail]>

Hi i just tried out the wnos 4a9 code on ucsd.edu
this version still has the Memory Leak that ALL wnos versions
still seems to have.

To test for the leak do this:
create two tcp sessions to one host in VC mode, so that you have
eg, smtp + nntp to the same remote host. but going over the same
VC connection.
you will see that as one tcp session sends data to the ax25 buffer space
but has not been sent out over the ax25 VC connect to the other host
and then the other session sends data to the ax25 buffer the data is Lost
and so is the memory.
On My system this causes memory to drop at the rate of 2kb per session
and can cause a system reboot in 5 mins

I only use wnos as a router so i never looses tcp sessions to my UNIX boxes
the VC will reconnect and carry on the same.
**************************** NOTE *****************************************
The SAD news is that this is NOT cured in the WNOS-5 versions i have tested.
May be the next test version im waiting for will be fixed. (hopeing)
***************************************************************************

Ok. Barry.

PS. I would like to use JNOS or other-NOS-?? but WNOS is the only NOS that
Implements the DK5SG-wampes AX25 Autorouter.!!!!!
So if the OTHER Authors of NOS would add in an AX25 Autorouter. then for me
things may change.

------------------------------

Date: Wed, 17 Nov 93 11:09:27 GMT
From: Mike Chace <[e-mail]>
Subject: RE wnos4a9 wno4a9ps.zip
To: BARRY TITMARSH <[e-mail]>

>>>>> Regarding RE wnos4a9 wno4a9ps.zip; BARRY TITMARSH <[e-mail]> adds:

    BARRY> Hi i just tried out the wnos 4a9 code on ucsd.edu this version
    BARRY> still has the Memory Leak that ALL wnos versions still seems to
    BARRY> have.

    BARRY> To test for the leak do this: create two tcp sessions to one host
    BARRY> in VC mode, so that you have eg, smtp + nntp to the same remote
    BARRY> host. but going over the same VC connection.  you will see that as
    BARRY> one tcp session sends data to the ax25 buffer space but has not
    BARRY> been sent out over the ax25 VC connect to the other host and then
    BARRY> the other session sends data to the ax25 buffer the data is Lost
    BARRY> and so is the memory.  On My system this causes memory to drop at
    BARRY> the rate of 2kb per session and can cause a system reboot in 5 mins

 Hi Folks,

 Due to the memory leak problems when the WNOS4Ax versions appeared,
 I reverted the UK Release of WNOS4 to WNOS4 beta0. This version of
 the code doesn't exhibit the memory leak problem and hundreds of UK
 users have been happily using WNOS4 for the past year.

 Perhaps the problem is unique to the GWONLY (gateway only) config
 of the code as I regularly operate in the the environment that
 Barry mentions without such problems. Or perhaps the SCC or DRSI
 support that he uses are the root of the problem? I'm always using
 a KISS TNC or packet drivers to talk to G8BPQ.

 Cheers, Mike

------------------------------

Date: Tue, 16 Nov 1993 10:47:54 -0500
From: [e-mail] (k1io, FN42jk)
Subject: SLIP, AX.25, KISS, Etc...
To: [e-mail]

As a fellow OS/2 fan, I understand the need to minimize the amount of
hardware and OS dependency in NOS-like programs.  Using existing
TCP/IP packages (I'm partial to QVTnet myself, which I run in an OS/2
seamless window) is a useful approach.   But a "SLIP TNC" is not the
only way to handle this.

Let's assume we've got a real operating system, like OS/2 (now $49 if
you already have Windows 3.1) or some Unix variant. You've got
multitasking!  So it's reasonable to assume that your TCP/IP has some
kind of low-layer driver code attached to it.  In DOS, it's a Packet
Driver.  OS/2 and Linux have drivers too, not that they're necessarily
a lot of fun to write.  (I don't know, I never tried, but I don't know
how to play tuba either.)  Might it be  possible to create, for each
OS in question, an AX.25 driver?  This would look Just Like Ethernet
to the existing application.

Now since "drivers" are a bear, it might be possible to implement this
using the old multitasking trick:  Create a "software TNC" where the
SLIP'-to-AX.25 (that's slip-prime, since the serial line might not be
there) function is a separate task, communicating with the NOS-program.
Why use a separate box when your PC can emulate one?  Now if it's a
Unix variant, I suppose it's easy enought to redirect.  If it's OS/2,
I dunno how to do interprocess communication, but there's probablyu
some neat hack possible.

Just an idea....
   fred k1io

------------------------------

Date: 16 Nov 1993 08:35:12 -0600 (cst)
From: [e-mail]
Subject: SLIP, AX.25, KISS, Etc...
To: [e-mail], [e-mail]

HI...

Well, Brian slam dunked me, and he is partially right! I was deliberately
ignoring the point that INET ain't ready for prime-time! It won't be until
after the additional address space is opened up and comercialism has made
everything "warm and fuzzy". (god forbid!!!! but that is "progress?")

BUT....

I really think device/os independence is a key concept! I was not saying "TNC"
as in tapr2.... I was thinking in an "open" sense like a busmastered
coprocessor x86 card, or x86 box running dedicated (but easily maintainable)
software.... after all you can get a 386sx-25 motherboard and peripherals for
under $200 (sans nice video)... add a dedicated iface card that can handle the
speed and you have spent what you would on a PK-232 or the like (US $325-350)

HMM... makes me think.... could NOS be rewritten to replace COMMAND.COM as
command processor? say... using the dos "kernal" from about v3.1? Or is this a
Gracilis Box story all over again??? ;-)

on a different matter:
to Steve Sampson... You can still get new clones of the NE1000 card with AUI
connectors ($49!).... would that be the sort of thing you mean for the
microwave project?

73
*********************************************************************
* Dr. John Spitznagel                  *   Sancho Panza Institute   *
* Internet: [e-mail]      *    for Advanced Studies    *
* AMPRNet:  [e-mail]       *  Department of Bogometrics *
* CIS:      76044,476                  *                            *
* Tel:      [phone]             *  (C) JKS, 1993             *
*********************************************************************

------------------------------

Date: Tue, 16 Nov 1993 9:33:31 -0800 (PST)
From: George Farris <[e-mail]>
Subject: SLIP, AX.25, KISS, Etc...
To: [e-mail]

>John Spitznagel writes:
>
>You are making one bogus assumption... The PC/micro world is Intel/DOS
>dominated, but remember, the remainder of "computerdom" is not.  The point many
>of us have been trying to make is that there is a place for a TNC that contains
>ALL the "intelligence" needed for a particular network hardware layer.  Those

stuff deleted

>
>There are TCP/IP stacks and tons of PD and shareware TCP/IP apps that could be
>used over high speed radio links if a TNC was designed to talk SLIP or ETHERNET
>(Ron... I like that idea.... but cost?) locally. Doing it all on the PC takes
>up memory, slows thruput (ask DRSI owners if they wish they had DMA driven
>boards now!) and locks the user into a monolithic program like NOS.  In System
>7, OS/2, Windoze, NT, and UNIX variants, one should be able to use  the
>native TCP stack and "your own favorite Telnet" app window/session to log on at
>a remote host while "FTP'ing" from another -or- better yet, not using either...
>but rather using Gopher, which does both in a very friendly way!
>

This in my opinion is what we really require.  MS-DOS (lets not let Microsoft
think they own the world by calling it DOS) will eventually go the way of the
dinos'.  A TNC designed to talk ethernet on one end and ax.25 (and other better
protocols when they come) on the other, will open up a whole world of pointy,
clicky, fill in the blank type of applications that all the MS-DOS, MAC,
MS-WINDOWS etc, people like.  Also if you think that a 386 is going to keep
up with doing all the protocol packing and unpacking in software and talk to
a high speed packet link well your looking forward to a good introduction to
assembly language..yech!

Come on guys lets try to think ahead and do whats going to serve us best in
the coming years.  1200bps packet should at best be thrown out the window,
at worst it should be outlawed as a terrible waste of frequency spectrum.
Right now 1200bps is only useable for mail links and as MIME standards come
up to speed and people start mailing sound and pictures...well you can
forget 1200bps altogether.  We need a good high speed interface between our
computers (not operating systems) and radio.  Ethernet is standard, supported
the world over and will handle everything we can throw at it RF wise in
the immediate future.  In the Intel world you should start to see some of
the motherboards come with ethernet built in fairly soon.

======================================================================
George Farris - VE7FRG          Internet  :  [e-mail]
Mill Bay, B.C.                      UUCP  :  sol.uvic.ca!ve7frg!george
Canada                         Phone/Fax  :  [phone]

------------------------------

Date: Tue, 16 Nov 93 09:47:35 -0600
From: [e-mail] (Steve Brown)
Subject: SLIP, AX.25, KISS, Etc...
To: [e-mail]

Brian,

You write:

  [... initial stuff deleted ...]

> Y'see, as I view it, even if you make NOS or something like it pretty
> and user-friendly and warm and cuddly, the damn NETWORK isn't going to
> be any of those things any time soon, so all you're doing is painting
> the leaves gold while the roots wither.
>
> We have to get the NETWORK working better first before we can even try
> to spread things to the masses, and I don't see very many people working
> on THAT.

Well said.  IMHO, there are at least a couple of reasons the network
takes lower priority than the programming work:

1) Putting together networks takes cooperation.  A single individual
   or small group of individuals can accomplish much more programming
   than (s)he or they can building networks.

2) Building networks involves ham _radio_.  I think my views on this
   issue are reasonably well known.  I also know that the question
   of why we don't discuss more hardware issues on tcp-group comes
   up periodically, gets about two responses, and then drops into
   the grass.

3) Networks are made of equipment that is suitable for only one
   application.  It is a lot harder to justify buying a lot of
   RF stuff to stick on some microwave tower somewhere than it
   is to justify buying a(nother) computer that, after all,
   _can_ be used for something else.

> Hams have much to much of a reputation for accepting any old shit
> that'll work, regardless of how poor the performance is.  Let's see if
> we can't do better than that here.  Sure, chrome sells, but performance
> is what is really needed.
>  - Brian

I certainly agree.

Before I have to get out my flame-resistant clothing, let me state
that I am in total awe of the work that Phil and all the other
programmers have done.  I am not anti-software or anti-programmer.  I
am a software design engineer by profession.

I don't have any simple, easy-to-understand, wrong solutions to the
problem.  I do have some questions:

1) Is there some software component of a potential network node that
   could potentially attract and hold the interest of the programmer
   community?   How about Phil's forward error correction stuff?

2) Would we gain anything by forming some sort of group to design and
   develop a network node package?  Are there already groups working
   this approach?  Would there be any benefit to "packaging" some sort
   of network node from existing work?  I suspect that there would
   since I have heard Jack, KF5MG, (and others?) ask many times for
   information on high-speed links, etc.

Enough already.  Thanks for the bandwidth,

              *********************************************
              |  Steve Brown, WD5HCY         |            |
              |  [e-mail]   | Simplicate |
              |  [e-mail]      | and add    |
              |       [44.28.0.61]           | lightness. |
              |                              |            |
              *********************************************

------------------------------

Date: Tue, 16 Nov 93 18:48:17 GMT
From: [e-mail] (Adrian Godwin)
Subject: SLIP, AX.25, KISS, etc...
To: [e-mail]

> From: [e-mail]

>
> There are TCP/IP stacks and tons of PD and shareware TCP/IP apps that could be
> used over high speed radio links if a TNC was designed to talk SLIP or ETHERNET
> (Ron... I like that idea.... but cost?) locally. Doing it all on the PC takes

Perhaps quite cheaply .. I've been considering this for a while on the grounds
that an NE1000 card costs $100 or less (much cheaper second-hand), and has an
interface that might hack rather nicely onto the Z80. The result would be a
TNC where only the HDLC port would need fast interrupt response due to the
buffering performed by the ethernet controller.

Considering that an apple II can handle localtalk at 230kbps by polling an
8530 in a tight loop, it might be possible to get fairly high speeds out of
the system (though I don't think the Z80 SIO has the 8530's 3-byte fifo).

What protocols should such a unit run ? Clearly, an IP router would be the
best possible solution, but I think fragmentation might be too much for it.
Perhaps just stuffing AX25 frames into UDP packets, or even raw ethernet
packets would be easier : it would still require a daemon on the host to
pass them onto the local IP kernel, but would at least create a generic radio
interface that can handle reasonable data rates without putting a crippling
interrupt load on the host.

How do terminal servers work - do they provide a telnet connection to the
serial ports with an IP stack within the terminal server, or do they
use a private protocol to talk to a support daemon on the host ?

-adrian

------------------------------

Date: Tue, 16 Nov 93 18:48:17 GMT
From: [e-mail] (Adrian Godwin)
Subject: SLIP, AX.25, KISS, etc...
To: [e-mail]

> From: [e-mail]

>
> There are TCP/IP stacks and tons of PD and shareware TCP/IP apps that could be
> used over high speed radio links if a TNC was designed to talk SLIP or ETHERNET
> (Ron... I like that idea.... but cost?) locally. Doing it all on the PC takes

Perhaps quite cheaply .. I've been considering this for a while on the grounds
that an NE1000 card costs $100 or less (much cheaper second-hand), and has an
interface that might hack rather nicely onto the Z80. The result would be a
TNC where only the HDLC port would need fast interrupt response due to the
buffering performed by the ethernet controller.

Considering that an apple II can handle localtalk at 230kbps by polling an
8530 in a tight loop, it might be possible to get fairly high speeds out of
the system (though I don't think the Z80 SIO has the 8530's 3-byte fifo).

What protocols should such a unit run ? Clearly, an IP router would be the
best possible solution, but I think fragmentation might be too much for it.
Perhaps just stuffing AX25 frames into UDP packets, or even raw ethernet
packets would be easier : it would still require a daemon on the host to
pass them onto the local IP kernel, but would at least create a generic radio
interface that can handle reasonable data rates without putting a crippling
interrupt load on the host.

How do terminal servers work - do they provide a telnet connection to the
serial ports with an IP stack within the terminal server, or do they
use a private protocol to talk to a support daemon on the host ?

-adrian

------------------------------

Date: Tue, 16 Nov 1993 11:44:24 -0800
From: [e-mail] (Brian Kantor)
Subject: UCSD master nameserver for ampr.org
To: [e-mail]

Just a brief reminder for those of you who obviously don't know what
you're doing:

You CANNOT have a CNAME entry whose left-hand-side is the same as any
other entry.  This is because you can't have additional data of any
kind for a cname.  CNAMES are simply nicknames for hosts.  They take on
all the other attributes of the host, and cannot have any of their own.

Please, if you don't understand this, don't send in CNAME entries to
the nameserver robot!

I thank you.
 - Brian

------------------------------

Date: Wed, 17 Nov 93 12:03:39 CET
From: BARRY TITMARSH <[e-mail]>
Subject: wnos-5 more
To: TCP-GROUP <[e-mail]>

To follow up on my last.
the memory leak i have seen in wnos4 and wnos5
are both related to a config: as..

2 ax25 ports via DRSI 1200bd 300 buf-size
1 ethernet NE2000 + packet driver  2048 buf-size
1 arcnet + packet driver 2048 buf-size
1 slip asy port 9600bd 1024 buf-size
2 kiss asy ports 9600bd 1024 buf-size

mem bufs 20 buf size 2048

System cfg as router no servers.

Only the ax25 ports on the SCC / DRSI are the problem.
If any one else can use this type of config and not SEE a memory leak
on any other type of NOS please tell me what NOS version you use.
Thanks.
Barry

------------------------------

End of TCP-Group Digest V93 #299
******************************
******************************